In `@build.gradle`:
- Line 37: Remove the duplicate dependency declaration of
'org.springframework.boot:spring-boot-starter-data-jpa' (keep only one
occurrence) and fix the inconsistent indentation on the remaining declaration by
converting the leading spaces to a tab so it matches the file's existing
indentation style; locate the duplicate by searching for the exact dependency
string and update the earlier occurrence's indentation accordingly.

In `@src/main/java/com/web/SearchWeb/config/CommonErrorCode.java`:
- Around line 9-11: The enum CommonErrorCode currently defines
INTERNAL_SERVER_ERROR with code "C006"; verify the intended numbering scheme and
either adjust the code value on INTERNAL_SERVER_ERROR to the correct sequence
(e.g., "C001" if it should be first) or add/document the missing placeholders
for C001–C005 and a comment explaining the numbering convention; update the enum
constant (INTERNAL_SERVER_ERROR) and associated documentation/comments to
reflect the chosen, consistent code scheme.

In `@src/main/java/com/web/SearchWeb/config/GlobalExceptionHandler.java`:
- Around line 26-33: Add a specific handler for IllegalArgumentException in
GlobalExceptionHandler so client validation errors from
MemberFolderServiceImpl.validateFolderName() return 400 instead of being caught
by the generic handleException(Exception). Implement a new method (e.g.,
handleIllegalArgumentException) annotated with
`@ExceptionHandler`(IllegalArgumentException.class) that logs at WARN/INFO and
returns
ResponseEntity.status(HttpStatus.BAD_REQUEST).body(ApiResponse.fail(...)) using
an appropriate client-error CommonErrorCode (or add one if missing);
alternatively, change MemberFolderServiceImpl.validateFolderName() to throw a
BusinessException subclass so the existing BusinessException handler handles it.

In
`@src/main/java/com/web/SearchWeb/folder/controller/dto/MemberFolderRequests.java`:
- Around line 8-13: Remove the ownerMemberId field from the
MemberFolderRequests.Create DTO (so it is no longer accepted from the request
body) and update the folder creation flow to derive the owner ID from the
authenticated principal instead (e.g., obtain memberId from
SecurityContextHolder or an `@AuthenticationPrincipal` argument in the controller
method that handles Create). Ensure the controller no longer reads
Create.ownerMemberId but passes the principal-derived memberId into the
service/repository create method (keeping parentFolderId, folderName,
description on Create unchanged) so owner assignment is done server-side and
IDOR is eliminated.
- Around line 3-28: The DTOs in MemberFolderRequests (inner classes Create,
Update, Move) lack Bean Validation and use public mutable fields; change each
DTO to encapsulate fields (make them private and provide getters/setters or
apply Lombok annotations like `@Getter/`@Setter/@NoArgsConstructor) and add
appropriate javax.validation annotations: for Create.folderName use `@NotBlank`
and `@Size`(max=...) (and `@NotNull` for ownerMemberId), for Update.folderName use
`@NotBlank/`@Size as needed, and for Move.newParentFolderId use `@NotNull` if moving
is required (or omit if null allowed); finally ensure controller methods that
accept these DTOs annotate the `@RequestBody` parameters with `@Valid` so validation
runs on entry.

In
`@src/main/java/com/web/SearchWeb/folder/controller/dto/MemberFolderResponses.java`:
- Line 9: The DTO class MemberFolderResponses is named in plural but represents
a single folder response; rename the class to MemberFolderResponse to match
semantics and update all references/usages (imports, constructors, builders,
JSON serializers, controller/service method return types, and any tests) to use
MemberFolderResponse instead of MemberFolderResponses; if any code expects a
collection, convert those signatures to use List<MemberFolderResponse> or
Collection<MemberFolderResponse> accordingly and run/refactor compilation fixes
and imports.

In
`@src/main/java/com/web/SearchWeb/folder/controller/MemberFolderController.java`:
- Around line 89-94: Change the DELETE handler to return HTTP 204 No Content
instead of a 200 with a body: update the MemberFolderController.delete method
signature to return ResponseEntity<Void> (remove the ApiResponse wrapper), call
memberFolderService.delete(folderId) as before, and return
ResponseEntity.noContent().build(); ensure imports and any callers are updated
to expect no body. This references MemberFolderController.delete and
memberFolderService.delete.
- Around line 31-41: Add Bean Validation to the create endpoint by annotating
the controller parameter in MemberFolderController.create with `@Valid` and
applying appropriate validation annotations to fields in
MemberFolderRequests.Create (e.g., `@NotNull` on ownerMemberId, `@NotBlank` on
folderName, leave parentFolderId nullable). Also add or update a handler in
GlobalExceptionHandler to catch MethodArgumentNotValidException and return a
clear ApiResponse error so validation failures produce controlled HTTP 400
responses.

In `@src/main/java/com/web/SearchWeb/folder/dao/MemberFolderJpaDao.java`:
- Around line 7-17: The delete path currently calls
MemberFolderServiceImpl.delete() which only invokes deleteById() and thus leaves
child folders orphaned or causes FK constraint failures; add a repository method
like MemberFolderJpaDao.deleteAllByParentFolderId(Long parentFolderId) and
update MemberFolderServiceImpl.delete() to recursively delete child folders (or
iterate breadth-first using deleteAllByParentFolderId), or alternatively
annotate the MemberFolder entity with cascade delete/orphanRemoval (e.g.,
orphanRemoval=true or `@Cascade`(CascadeType.ALL)) to ensure children are removed
automatically—pick one approach and implement the repository method or entity
cascade and adjust the service to use it.

In `@src/main/java/com/web/SearchWeb/folder/domain/MemberFolder.java`:
- Around line 23-34: Add audit fields to the MemberFolder entity: declare
createdAt and updatedAt (e.g., Instant or LocalDateTime) and annotate them with
`@CreatedDate` and `@LastModifiedDate` respectively; annotate the entity with
`@EntityListeners`(AuditingEntityListener.class) so JPA will populate them, and
ensure Spring Data JPA auditing is enabled in the application (EnableJpaAuditing
in a config class) so MemberFolder's createdAt/updatedAt are automatically
maintained on persist/update.
- Around line 15-18: The class MemberFolder currently uses `@AllArgsConstructor`
with default (public) visibility together with `@Builder`, exposing a public
all-args constructor; change the AllArgsConstructor to be private by replacing
`@AllArgsConstructor` with `@AllArgsConstructor`(access = AccessLevel.PRIVATE) so
the builder remains usable but the public all-args constructor is not exposed
(target the MemberFolder class annotations).
- Around line 44-46: In MemberFolder.changeParent, prevent setting a folder as
its own parent by validating that newParentFolderId is not equal to
this.memberFolderId; if they are equal, throw an IllegalArgumentException (or a
domain-specific exception) instead of assigning to parentFolderId. Update the
method (changeParent) to perform this check before assigning this.parentFolderId
= newParentFolderId; keep additional indirect-cycle validation for the service
layer that inspects ancestor chains.

In `@src/main/java/com/web/SearchWeb/folder/error/FolderErrorCode.java`:
- Around line 10-16: FolderErrorCode defines DUPLICATE_FOLDER_NAME but
MemberFolderServiceImpl lacks duplicate-name validation; add a check in
MemberFolderServiceImpl (in create/update folder methods) to query the
repository for existing folder names for the member (e.g., using
FolderRepository methods or findByMemberAndName) and, if a conflict exists,
throw your domain exception using FolderErrorCode.DUPLICATE_FOLDER_NAME; also
implement the PR-mentioned cap (e.g., MAX_FOLDERS = 64) by counting existing
member folders before create and throw a suitable error if the limit is reached.

In `@src/main/java/com/web/SearchWeb/folder/service/MemberFolderService.java`:
- Around line 13-15: The two service methods listRootFolders and listChildren on
MemberFolderService currently return full lists and should support pagination
for scalability; change their signatures to accept a Pageable (e.g.,
List<MemberFolder> listRootFolders(Long ownerMemberId, Pageable pageable) ->
Page<MemberFolder> listRootFolders(Long ownerMemberId, Pageable pageable)) (or
return Slice<MemberFolder>), then update all implementations of
MemberFolderService (and any callers) to use the Pageable param and return a
Page/Slice, and adapt underlying repository calls (e.g.,
repository.findByOwnerIdAndParentIsNull(ownerId, pageable) and
repository.findByOwnerIdAndParentId(ownerId, parentId, pageable)) to pass the
PageRequest so only one page (e.g., size 64 default) is fetched.
- Line 5: The file MemberFolderService.java imports java.util.Optional but does
not use it in the interface method signatures; remove the unused import (delete
the line "import java.util.Optional;") and run a quick compile or IDE organize
imports to ensure no other references to Optional remain in MemberFolderService
or its methods.

In `@src/main/java/com/web/SearchWeb/folder/service/MemberFolderServiceImpl.java`:
- Around line 17-30: The create method and other mutating methods (update, move,
delete) lack ownerMemberId-based authorization checks, allowing IDOR; add an
ownership validation step in MemberFolderServiceImpl before performing any
update/move/delete (and optionally before read if needed): fetch the target
MemberFolder via memberFolderJpaRepository.findById(memberFolderId) and compare
its ownerMemberId to the caller-provided ownerMemberId, throwing an appropriate
exception (e.g., AccessDeniedException or custom) if they differ; factor this
into a reusable private method like validateOwnerOrThrow(Long ownerMemberId,
Long memberFolderId) and call it from update, move, delete (and any other
mutating methods) to prevent unauthorized operations.
- Around line 63-69: The move(Long memberFolderId, Long newParentFolderId)
method in MemberFolderServiceImpl must validate the new parent: first load the
target parent via memberFolderJpaRepository.findById(newParentFolderId) and
throw FolderException.NotFound if missing; then prevent cycles by rejecting if
newParentFolderId equals memberFolderId or if the target parent is a descendant
of the folder being moved (traverse the parent chain of the loaded parent or
query the folder's subtree to see if any id equals memberFolderId); if
validation fails throw an appropriate FolderException (e.g., InvalidParent)
instead of calling folder.changeParent, otherwise proceed to changeParent.
Ensure checks occur inside the same transactional method so state is consistent.
- Around line 71-78: The delete(Long memberFolderId) currently removes only the
parent and leaves orphaned children; update delete() to handle children using
the existing listChildren(Long parentId) helper: either recursively delete each
child by calling delete(childId) before calling
memberFolderJpaRepository.deleteById(memberFolderId), or iterate children and
set their parentFolderId to null (or the root indicator) and save them via
memberFolderJpaRepository.save/update before deleting the parent; ensure
operations remain within the `@Transactional` boundary and still use
memberFolderJpaRepository.deleteById(...) for removing the parent.